feat: land RFC-0024 ring VRF key management - #360
Conversation
|
@pgherveou RFC-0024 from #348 is rebased and fully integrated onto current main here, with Extrinsic V5 and canonical native FFI preserved. All required CI is green and auto-merge is enabled. Please review the integration when available; UserAgentKit #1653 is ready to re-vendor the immutable merge commit immediately afterward. |
|
@pgherveou CI is now fully green at |
|
Quick Update on this: on protocol implementation it all looks good. I am finding some timeouts in the battery tests using the signing host, that are not present in #348 |
This branch forked before chain.get_chain_info landed on main claiming request id 166, so the three RFC-0024 account methods were allocated the same id. Shift them to 168/170/172 and leave 166 free for the chain method arriving on merge. Regenerates the server wire table and updates the codegen golden.
Chain the two follow-alias resolvers in chain_runtime so a product-scoped alias resolves against pending intents and awaits setup before binding to the transport follow. Point the getAccountAlias example at chain.getChainInfo, and reach the platform through RuntimeServices in the ring VRF paths. Wire ids: chain.getChainInfo 166, ring VRF 168/170/172.
Resolve through the connection's sticky alias binding first, so pending intents only cover a request that beats follow setup. A second follow on a chain made the intent lookup ambiguous and failed every aliased operation on it.
Funding claimed 168-179, which collides head-on with the ring VRF key management methods landing in #360 (168-173). The RFC justified starting at 168 on the basis that #335 held 166-167; those are actually held by Chain::get_chain_info, so the rationale was wrong independently of the collision. Funding now takes 176-187, leaving 168-173 for #360 and 174-175 for #335. The id-allocation paragraph names the real holders of each preceding block.
|
@valentunn @johnthecat @ERussel could I please get a check to get this merged? |
5 participants
Summary
mainfeature/people-rfcRFC source while retaining registration, listing, selection, direct signing, AutoSigning, pairing, and battery coverageDerivationIndex::Index/Rawand expose native provider selection with canonicalRingLocationandProductAccountIdrecordsBreaking change: a
RingLocationneeds an explicitCollectionIdProof and alias generation read the ring's collection from a
CollectionIdjunction. A location that carries none is not a ring: it resolves to
RingNotFound. APalletInstancejunction alone does not identify a ring.Migration:
createAccountProof,getAccountAlias, andregisterRingVrfKeycalls each carry a
CollectionIdjunction naming their ring. Callers thatdepended on the host substituting full personhood name
pop:polkadot.network/peopleexplicitly.Exposure: every ring location in this repo — generated client examples,
playground, host CLI battery, and the RFC-0024 docs — names its collection,
so nothing here depends on the substitution. Products outside this repo that
omit the junction need the change above.
Immutable source
Candidate source:
ccf3b5c07db99b6a46f802baa8b189e0f658780cIntegration parents:
main:5e3c6c4bc2597d958f997a4b87d0776fec33e01320c1d4a62d95746eaec9f77c73661a183c6db04fUserAgentKit PR #1653 vendors this exact candidate.
Verification
cargo test -p truapi-server --all-features: 512 passed across 6 suitescargo check -p truapi-server --target wasm32-unknown-unknown --all-features: passedcargo fmt --all -- --check: passed./scripts/codegen.sh: no drift against the committed generated client and wire tables@parity/truapi:npm run buildand 221 bun tests passedyarn buildandyarn lintpassed, including the generated client examplesRFC acceptance remains tracked in #324.